Uz notikumiem balstīta arhitektūra: Ziņojumu veidņu apguve mērogojamām sistēmām

Uz notikumiem balstīta arhitektūra (EDA) ir programmatūras arhitektūras paradigma, kas koncentrējas uz notikumu ražošanu, noteikšanu un patēriņu. Tā vietā, lai pakalpojumu mijiedarbība būtu cieši saistīta, EDA veicina asinhronu komunikāciju, kā rezultātā sistēmas kļūst mērogojamākas, noturīgākas un atsaistītākas. EDA galvenā sastāvdaļa ir efektīva ziņojumu veidņu izmantošana. Šis ceļvedis pēta dažādas ziņojumu veidnes, ko parasti izmanto EDA, sniedzot praktiskus piemērus un labāko praksi globālajām izstrādes komandām.

Kas ir uz notikumiem balstīta arhitektūra?

Tradicionālajā pieprasījuma/atbildes arhitektūrā pakalpojumi tieši izsauc viens otru. Šī ciešā saistība var radīt vājās vietas un padarīt sistēmas trauslas. EDA savukārt atsaista pakalpojumus, ieviešot notikumu kopni vai ziņojumu starpnieku. Pakalpojumi sazinās, publicējot notikumus kopnei, un citi pakalpojumi abonē notikumus, kas tos interesē. Šī asinhronā komunikācija ļauj pakalpojumiem darboties neatkarīgi, uzlabojot mērogojamību un kļūdu toleranci.

EDA galvenās priekšrocības

• Atsaistīšana: Pakalpojumi ir neatkarīgi un nav jāzina viens par otru.
• Mērogojamība: Atsevišķus pakalpojumus var mērogot neatkarīgi, pamatojoties uz pieprasījumu.
• Noturība: Viena pakalpojuma kļūme ne vienmēr ietekmē citus pakalpojumus.
• Elastīgums: Jaunus pakalpojumus var pievienot vai noņemt, neietekmējot esošos pakalpojumus.
• Reāllaika atsaucība: Pakalpojumi var reaģēt uz notikumiem gandrīz reāllaikā.

Bieži sastopamās ziņojumu veidnes uz notikumiem balstītā arhitektūrā

EDA var izmantot vairākas ziņojumu veidnes, katrai no tām ir savas stiprās un vājās puses. Pareizās veidnes izvēle ir atkarīga no jūsu lietojumprogrammas īpašajām prasībām.

1. Publicēšana-Abonēšana (Pub-Sub)

Publicēšanas-abonēšanas veidne ir viena no fundamentālākajām ziņojumu veidnēm EDA. Šajā veidnē publicētāji rada ziņojumus tēmai vai apmaiņai, un abonenti reģistrē savu interesi par konkrētām tēmām. Pēc tam ziņojumu starpnieks novirza ziņojumus no publicētājiem visiem ieinteresētajiem abonentiem.

Piemērs

Apsveriet e-komercijas platformu. Kad klients veic pasūtījumu, notikums "PasūtījumsIzveidots" tiek publicēts tēmai "Pasūtījumi". Pakalpojumi, piemēram, inventāra pakalpojums, maksājumu pakalpojums un piegādes pakalpojums, abonē tēmu "Pasūtījumi" un attiecīgi apstrādā notikumu.

Ieviešana

Pub-Sub var ieviest, izmantojot ziņojumu starpniekus, piemēram, Apache Kafka, RabbitMQ, vai mākoņa ziņojumu pakalpojumus, piemēram, AWS SNS/SQS vai Azure Service Bus. Konkrētās ieviešanas detaļas atšķiras atkarībā no izvēlētās tehnoloģijas.

Priekšrocības

• Atsaistīšana: Publicētāji un abonenti ir pilnībā atsaistīti.
• Mērogojamība: Abonentus var pievienot vai noņemt, neietekmējot publicētājus.
• Elastīgums: Var ieviest jaunus notikumu tipus, neprasot izmaiņas esošajos pakalpojumos.

Trūkumi

• Sarežģītība: Tēmu un abonementu pārvaldība var kļūt sarežģīta lielās sistēmās.
• Iespējamā konsekvence: Abonenti var nesaņemt notikumus nekavējoties, kas noved pie iespējamās konsekvences.

2. Notikumu avots

Notikumu avots ir veidne, kurā visas lietojumprogrammas stāvokļa izmaiņas tiek fiksētas kā notikumu secība. Tā vietā, lai glabātu pašreizējo entītijas stāvokli, lietojumprogramma glabā notikumu vēsturi, kas noveda pie šī stāvokļa. Pašreizējo stāvokli var rekonstruēt, atkārtoti atskaņojot notikumus.

Piemērs

Apsveriet bankas lietojumprogrammu. Tā vietā, lai glabātu konta pašreizējo atlikumu, lietojumprogramma glabā tādus notikumus kā "Depozīts", "Izņemšana" un "Pārskaitījums". Pašreizējo atlikumu var aprēķināt, secīgi atkārtojot šos notikumus.

Ieviešana

Notikumu avots parasti ietver notikumu glabāšanu notikumu krātuvē, kas ir specializēta datubāze, kas optimizēta notikumu glabāšanai un izgūšanai. Apache Kafka bieži tiek izmantota kā notikumu krātuve, pateicoties tās spējai apstrādāt lielu notikumu apjomu un nodrošināt stingras pasūtīšanas garantijas.

Priekšrocības

• Audita iespējas: Ir pieejama visa izmaiņu vēsture.
• Atkļūdošana: Vieglāk atkļūdot problēmas, atkārtoti atskaņojot notikumus.
• Laika vaicājumi: Spēja veikt vaicājumus par lietojumprogrammas stāvokli jebkurā brīdī.
• Atkārtota atskaņošana: Spēja atkārtoti atskaņot notikumus, lai atjaunotu stāvokli vai izveidotu jaunas projekcijas.

Trūkumi

• Sarežģītība: Notikumu avota ieviešana var būt sarežģīta.
• Glabāšana: Nepieciešama liela notikumu datu apjoma glabāšana.
• Vaicājumi: Notikumu krātuves vaicājumi var būt sarežģīti.

3. Komandu un vaicājumu atbildības nošķiršana (CQRS)

CQRS ir veidne, kas atdala datu glabātuves lasīšanas un rakstīšanas darbības. Tā definē divus atšķirīgus modeļus: komandu modeli rakstīšanas darbību apstrādei un vaicājumu modeli lasīšanas darbību apstrādei. Šī atdalīšana ļauj katru modeli optimizēt tā īpašajam mērķim.

Piemērs

E-komercijas lietojumprogrammā komandu modelis varētu apstrādāt tādas darbības kā pasūtījumu izveide, produkta informācijas atjaunināšana un maksājumu apstrāde. Vaicājumu modelis varētu apstrādāt tādas darbības kā produktu sarakstu attēlošana, pasūtījumu vēstures rādīšana un atskaišu ģenerēšana.

Ieviešana

CQRS bieži tiek izmantots kopā ar notikumu avotu. Komandas tiek izmantotas, lai iedarbinātu notikumus, kas pēc tam tiek izmantoti lasīšanas modeļu atjaunināšanai. Lasīšanas modeļus var optimizēt noteiktiem vaicājumu modeļiem, nodrošinot ātrāku un efektīvāku lasīšanas veiktspēju.

Priekšrocības

• Veiktspēja: Lasīšanas un rakstīšanas darbības var optimizēt neatkarīgi.
• Mērogojamība: Lasīšanas un rakstīšanas modeļus var mērogot neatkarīgi.
• Elastīgums: Lasīšanas un rakstīšanas modeļi var attīstīties neatkarīgi.

Trūkumi

• Sarežģītība: CQRS ieviešana var ievērojami palielināt sarežģītību.
• Iespējamā konsekvence: Lasīšanas modeļi var nebūt nekavējoties saskaņoti ar rakstīšanas modeli.

4. Pieprasījums-Atbilde

Lai gan EDA veicina asinhronu komunikāciju, ir scenāriji, kuros pieprasījuma-atbildes veidne joprojām ir nepieciešama. Šajā veidnē pakalpojums nosūta pieprasījuma ziņojumu citam pakalpojumam un gaida atbildes ziņojumu.

Piemērs

Lietotāja saskarne var nosūtīt pieprasījumu aizmugures pakalpojumam, lai izgūtu lietotāja profila informāciju. Aizmugures pakalpojums apstrādā pieprasījumu un nosūta atbildi, kas satur lietotāja profila datus.

Ieviešana

Pieprasījuma-atbildes veidni var ieviest, izmantojot ziņojumu starpniekus ar atbalstu pieprasījuma-atbildes semantikai, piemēram, RabbitMQ. Pieprasījuma ziņojums parasti ietver korelācijas ID, kas tiek izmantots, lai atbildes ziņojumu saskaņotu ar sākotnējo pieprasījumu.

Priekšrocības

• Vienkārša: Salīdzinoši vienkārša ieviešanā, salīdzinot ar citām ziņojumu veidnēm.
• Sinhronizēta veida: Nodrošina sinhronizēta veida mijiedarbību, izmantojot asinhronu ziņojumapmaiņas infrastruktūru.

Trūkumi

• Cieša saistība: Pakalpojumi ir ciešāk saistīti, salīdzinot ar tīri asinhronām veidnēm.
• Bloķēšana: Pieprasīšanas pakalpojums bloķējas, gaidot atbildi.

5. Saga

Saga ir veidne ilgtermiņa darījumu pārvaldībai, kas aptver vairākus pakalpojumus. Izplatītā sistēmā viens darījums var ietvert atjauninājumus vairākās datubāzēs vai pakalpojumos. Saga nodrošina, ka šie atjauninājumi tiek veikti konsekventi, pat kļūmju gadījumā.

Piemērs

Apsveriet e-komercijas pasūtījumu apstrādes scenāriju. Saga varētu ietvert šādus soļus: 1. Izveidot pasūtījumu pasūtījumu pakalpojumā. 2. Rezervēt inventāru inventāra pakalpojumā. 3. Apstrādāt maksājumu maksājumu pakalpojumā. 4. Nosūtīt pasūtījumu piegādes pakalpojumā.

Ja kāds no šiem soļiem neizdodas, sagai ir jākompensē iepriekšējie soļi, lai nodrošinātu sistēmas konsekventu stāvokli. Piemēram, ja maksājums neizdodas, sagai ir jāatceļ pasūtījums un jāatbrīvo rezervētais inventārs.

Ieviešana

Ir divas galvenās pieejas sagu ieviešanai: 1. Uz horeogrāfiju balstīta saga: Katrs sagā iesaistītais pakalpojums ir atbildīgs par notikumu publicēšanu, kas iedarbina nākamo soli sagā. Nav centrālā orķestratora. 2. Uz orķestrēšanu balstīta saga: Centrālā orķestratora pakalpojums pārvalda sagu un koordinē iesaistītos soļus. Orķestrators nosūta komandas iesaistītajiem pakalpojumiem un klausās notikumus, kas norāda uz katra soļa panākumiem vai neveiksmēm.

Priekšrocības

• Konsekvence: Nodrošina datu konsekvenci vairākos pakalpojumos.
• Kļūdu tolerance: Eleganti apstrādā kļūmes un nodrošina, ka sistēma atjaunojas konsekventā stāvoklī.

Trūkumi

• Sarežģītība: Sagu ieviešana var būt sarežģīta, īpaši ilgstošiem darījumiem.
• Kompensācijas loģika: Nepieciešama kompensācijas loģikas ieviešana, lai atsauktu neizdevušos soļu ietekmi.

Pareizās ziņojumu veidnes izvēle

Ziņojumu veidnes izvēle ir atkarīga no jūsu lietojumprogrammas īpašajām prasībām. Pieņemot lēmumu, ņemiet vērā šādus faktorus:

• Konsekvences prasības: Vai jums ir nepieciešama spēcīga konsekvence vai iespējamā konsekvence?
• Latentuma prasības: Cik ātri pakalpojumiem ir jāreaģē uz notikumiem?
• Sarežģītība: Cik sarežģīta ir veidnes ieviešana un uzturēšana?
• Mērogojamība: Cik labi veidne mērogojas, lai apstrādātu lielu notikumu apjomu?
• Kļūdu tolerance: Cik labi veidne apstrādā kļūmes?

Šeit ir tabula, kas apkopo katras ziņojumu veidnes galvenās īpašības:

Veidne	Apraksts	Konsekvence	Sarežģītība	Lietošanas gadījumi
Pub-Sub	Publicētāji sūta ziņojumus tēmām, abonenti saņem ziņojumus no tēmām.	Iespējama	Vidēja	Paziņojumi, notikumu izplatīšana, pakalpojumu atsaistīšana.
Notikumu avots	Glabā visas lietojumprogrammas stāvokļa izmaiņas kā notikumu secību.	Stingra	Augsta	Audits, atkļūdošana, laika vaicājumi, stāvokļa atjaunošana.
CQRS	Atdala lasīšanas un rakstīšanas darbības atsevišķos modeļos.	Iespējama (lasīšanas modeļiem)	Augsta	Lasīšanas un rakstīšanas veiktspējas optimizēšana, lasīšanas un rakstīšanas darbību neatkarīga mērogošana.
Pieprasījums-Atbilde	Pakalpojums nosūta pieprasījumu un gaida atbildi.	Tūlītēja	Vienkārša	Sinhronizēta veida mijiedarbība, izmantojot asinhronu ziņojumapmaiņu.
Saga	Pārvalda ilgstošus darījumus, kas aptver vairākus pakalpojumus.	Iespējama	Augsta	Izplatīti darījumi, datu konsekvences nodrošināšana vairākos pakalpojumos.

Labākā prakse EDA ziņojumu veidņu ieviešanai

Šeit ir dažas labākās prakses, kas jāņem vērā, ieviešot EDA ziņojumu veidnes:

• Izvēlieties pareizo ziņojumu starpnieku: Izvēlieties ziņojumu starpnieku, kas atbilst jūsu lietojumprogrammas prasībām. Apsveriet tādus faktorus kā mērogojamība, uzticamība un funkciju kopums. Populārās iespējas ietver Apache Kafka, RabbitMQ un mākoņa ziņojumu pakalpojumus.
• Definējiet skaidras notikumu shēmas: Definējiet skaidras un labi definētas notikumu shēmas, lai nodrošinātu, ka pakalpojumi var pareizi saprast un apstrādāt notikumus. Izmantojiet shēmu reģistrus notikumu shēmu pārvaldībai un validācijai.
• Ieviesiet idempotentas patērētājus: Nodrošiniet, lai jūsu patērētāji būtu idempotenti, tas nozīmē, ka tie var apstrādāt vienu un to pašu notikumu vairākas reizes, neradot nevēlamas blaknes. Tas ir svarīgi kļūmju apstrādei un notikumu uzticamai apstrādei.
• Uzraugiet savu sistēmu: Uzraugiet savu sistēmu, lai atklātu un diagnosticētu problēmas. Sekojiet galvenajiem rādītājiem, piemēram, notikumu latentumam, ziņojumu caurlaidspējai un kļūdu līmenim.
• Izmantojiet izplatīto izsekošanu: Izmantojiet izplatīto izsekošanu, lai izsekotu notikumiem, kad tie plūst caur jūsu sistēmu. Tas var palīdzēt identificēt veiktspējas vājās vietas un novērst problēmas.
• Apsveriet drošību: Nodrošiniet savu notikumu kopni un ziņojumu rindas, lai aizsargātu pret neatļautu piekļuvi. Izmantojiet autentifikāciju un autorizāciju, lai kontrolētu, kas var publicēt un abonēt notikumus.
• Eleganti apstrādājiet kļūdas: Ieviesiet kļūdu apstrādes mehānismus, lai apstrādātu kļūmes un nodrošinātu notikumu uzticamu apstrādi. Izmantojiet "dead-letter" rindas, lai glabātu notikumus, kurus nevar apstrādāt.

Reālās pasaules piemēri

EDA un ar to saistītās ziņojumu veidnes tiek izmantotas plašā nozaru un lietojumprogrammu spektrā. Šeit ir daži piemēri:

• E-komercija: Pasūtījumu apstrāde, krājumu pārvaldība, piegādes paziņojumi.
• Finanšu pakalpojumi: Krāpšanas atklāšana, darījumu apstrāde, riska pārvaldība.
• Veselības aprūpe: Pacientu uzraudzība, tikšanās plānošana, medicīnisko ierakstu pārvaldība.
• IoT: Sensoru datu apstrāde, ierīču pārvaldība, tālvadība.
• Sociālie mediji: Ziņu plūsmas atjauninājumi, paziņojumi, lietotāju aktivitātes izsekošana.

Piemēram, globāls pārtikas piegādes pakalpojums varētu izmantot EDA, lai pārvaldītu pasūtījumus. Kad klients veic pasūtījumu, tiek publicēts notikums `OrderCreated`. Restorāna pakalpojums abonē šo notikumu, lai sagatavotu ēdienu. Piegādes pakalpojums abonē šo notikumu, lai piešķirtu vadītāju. Maksājumu pakalpojums abonē šo notikumu, lai apstrādātu maksājumu. Katrs pakalpojums darbojas neatkarīgi un asinhroni, ļaujot sistēmai efektīvi apstrādāt lielu skaitu pasūtījumu.

Secinājums

Uz notikumiem balstīta arhitektūra ir jaudīga paradigma mērogojamu, noturīgu un atsaistītu sistēmu veidošanai. Izprotot un efektīvi izmantojot ziņojumu veidnes, izstrādātāji var izveidot stabilas un elastīgas lietojumprogrammas, kas var pielāgoties mainīgām biznesa prasībām. Šis ceļvedis sniedza pārskatu par bieži sastopamajām ziņojumu veidnēm, ko izmanto EDA, kā arī praktiskus piemērus un labāko praksi. Pareizās veidnes izvēle jūsu īpašajām vajadzībām ir ļoti svarīga veiksmīgu uz notikumiem balstītu sistēmu veidošanai. Pieņemot lēmumu, atcerieties ņemt vērā konsekvenci, latentumu, sarežģītību, mērogojamību un kļūdu toleranci. Izmantojiet asinhronās komunikācijas spēku un atklājiet pilnu savu lietojumprogrammu potenciālu.